An emulator reproduces the functionality of another system in one system. The difference with Computer Simulation is that the simulator is dedicated to mimicking the external behavior and behavior of the system, rather than the abstract model of the simulation system. See simulation and simulation terms.
Overview
The emulator is the hardware used to implement hardware emulation. The emulator can implement an alternative to the microcontroller to control the operation of the program, such as single-step, full-speed, view resource breakpoints, and so on. Although software emulation has the advantage of verifying the program without building a hardware circuit, it does not fully reflect the real hardware's health, so hardware simulation is required to complete the final design. Hardware emulation is required during development.
Simulator principle
The hardware resources such as the P port inside the emulator are basically compatible with the 51 series MCU. The emulation master program is stored in a special specified space of the emulator chip. There is a special address segment for storing the emulation master program. The emulation master program controls the correct operation of the emulator just like the operating system of a computer. The emulator and the host computer software (ie KEIL) on the computer are connected through the serial port. The RXD and TXD of the emulator chip are responsible for receiving the control data sent by the host computer, and the TXD is responsible for sending feedback information to the host computer. The control command is issued by KEIL, and the emulation master program inside the emulator is responsible for executing the received data and performing correct processing. In turn, the corresponding hardware work is driven, which also includes storing the received BIN or other formatted program into the memory unit of the emulator chip for storing the executable program (this process is similar to burning the program into the 51 chip). However, the emulator's erasing is done in the form of overlays, so that it is similar to the programmer's repeated programming to test the function! The difference is that the simulation master program can make these target programs perform certain operations, such as single step, specified breakpoint, specified address, etc., and the state of each memory cell inside the microcontroller can be observed in real time through KEIL. After the emulator and the computer host are connected, it is like the relationship between two precise gears, and the connection is forcibly interrupted (such as forcibly resetting the emulator manually or all the lines are connected), the computer will prompt online. The problem, which also reflects the characteristics of hardware simulation, that is, "what you see is what you get". These are all things the programmer can't do. These create a strong guarantee for debugging, modifying, and generating the final program, resulting in higher efficiency.
Problems using the emulator
The reliability of the simulator is very dependent on the level of its designer. With the complication of electronic devices, it is increasingly difficult for users of emulators to identify where the problems encountered in development are. Based on the trust in the simulator, the user will first suspect that the problem is from his own design. If the user finally finds that the problem is coming from the emulator after a lot of effort, the user may lose trust and give up using all emulators.
Some users consider the simulator to be unreliable and have little or no emulators in development. They use the following methods for development:
1. Build a hardware platform that meets your requirements based on your design. If the program involved in the platform is more complicated. It is also necessary to build a human-machine communication channel. The human-machine AC channel may be a simple LED, buzzer, and the complex interface may be a serial communication port LCD display.
2. Write a simple example of a program, such as letting the LEDs blink continuously. After the program is compiled, it is programmed into the MCU chip to verify whether the hardware platform is working properly.
3. After the hardware platform works normally, write the driver of the lowest level of the system, and re-program the MCU chip verification after each program change. If you encounter problems in the program verification, add some debugging methods in the program, such as sending some information to the HyperTerminal on the PC through the serial port to understand the running status of the program.
4. Write the user framework program after the system low-level driver is complete. Since this part does not involve hardware, the problems in the program are generally found by users.
However, for complex situations, such a hardware platform actually has the function of an emulator and functions as an emulator.
Emulator product service issues
When users use the emulator to develop products, they may encounter problems with the emulator, the product itself, and the user system, and resort to the emulator manufacturer. If the manufacturer of the emulator only focuses on the design of the emulator and is not familiar with the microcontroller application, it may not be able to make a correct judgment on the user's question. On the contrary, emulator manufacturers who are familiar with the use of emulators and have rich experience in MCU development have the ability to give technical support to users and help users to quickly find out the problem.